Software is alive! It’s born, its built, its tested, then its released. Throughout the life of the software, it is improved upon. Improvements could be new features, bug fixes, cosmetic changes, etc. Each improvement goes through its own lifecycle. The improvement is born, built, tested and released. The life of software is cyclic until it reaches the end of its life. Today we will be talking about the life of software. We call the life of software the Software Development Lifecycle, or SDLC. By the end of this episode, you’ll have a good grasp into the processes that make up the life of software.
The SDLC
I think the best was to visualize the SDLC is to see it, visually.
The image above describes the common theme in the different methodologies. Basically an idea is fed into the SDLC’s Requirement Analysis phase. This is where requirements are gathered and the idea is scoped into a project. From there, business people, developers, etc., design the system. Once a design is completed and everyone knows what is going to be built, it is handed off to a developer to implement. After the developer is finished, it is tested by others to ensure it does what it is supposed to do (requirements). If the software works as expected, it is delivered (released). Because most software evolves over time, the cycle repeats.
There are several forms of an SDLC. We call these SDLC methodologies. You can find out a lot more on the different methodologies here. I’ll quickly describe the different models at a high level.
Waterfall
The Waterfall Model is a linear model. It consists of phases that are sequential. In the diagram above, notice the arrows, they only point to the next phase. This means that the piece of software as a whole flows down. Basically it is fully defined in the Requirements phase, then it is totally designed in the Design phase, built in the Implementation phase, tested in the Verification phase, released, and then maintained in the Maintenance phase.
This model came from the manufacturing and construction industries. Because the environments of those industries are expensive to implement, everything was formed up front. This model is not in common use today.
Iterative Model
As software started to grow, it started to distance itself from the Waterfall Model. Because software and hardware changes so often, an Iterative Model started to come to light. Instead of building everything all at once, smaller steps were made. This allowed the software to evolve over time.
Spiral Model
The diagram above was defined in “A Spiral Model of Software Development and Enhancement” in 1986 by Barry Boehm. It was created to mitigate risk. The super high level definition is that it allows teams to adopt elements of one or more process models, such as incremental, waterfall, or evolutionary prototyping based on the risk of a project.
V-Model
The V-Model is essentially an extension of the Waterfall model. Everything is defined up front, but once it is developed, it can flow back to the definitions for testing.
Agile Model
The Agile Model is all about being able to quickly react to change. There are several different types of Agile Development such as Scrum, Kanban, and Lean. The general principle of the model is to be fast and flexible. Instead of planning everything up front, you start small and iterate, adapting to change along the way and delivering as soon as you can. Today, the Agile Model is widely used.
Phases
Now that we have a general idea of an SDLC and some different models used, we can work our way through the different phases of developing software.
Birth
When one thing ends, another begins. When one thing begins, another ends. In the beginning, there was an idea, or maybe it was a client request, maybe it was a problem, or a bug…let’s just call it a thing. In the beginning, there was this thing. What is this thing? That is where we begin. When a thing is born, it is defined. Typically business people will define it, argue about it, refine it and place the scope boundaries on it.
The process that does the defining can greatly vary based on the size of the company, the type of software and the methodology, or lack thereof. A company could have a single person take care of this step. This step could be done by the developer creating it. It could be done by an entire team. Usually the bigger the company is, the bigger the team that defines the thing is.
If a thing is decided that it should be done and it is defined and scoped, it is usually put into a system to help manage things. This system could be a whiteboard, or it could be a piece of software that handles these things. Systems like Jira, VersionOne , etc, are great tools for managing the lifecycle. I’ll go into these systems a bit more after we get through the steps in the process.
Planning
Once a thing is ready to start being built, a team will pick it up. As with all steps, this will vary, but I’m going to describe an enterprise level step. The team will get the thing and it will be placed in their backlog. A member of the team, typically called a Product Owner, will gather resources and any additional information to refine its definition. A Level of Effort (LOE) is typically given by a developer and a priority is set. A release date is usually able to be defined here as well, unless it was already determined in the Birth stage.
Next up, the thing is shown to the entire team. Also, forgot to mention, teams that operate in the model I’m describing are usually around 5-8 people, consisting of a Product Owner, developers and testers. The detail of planning could just be: Here is this thing and this is what it should do, do it. It could also be: Here is this thing, here is what it should do, how it should do it, how it should be tested, here are some diagrams, etc. I’ve seen teams go all the way to a class diagram level. I think that is overkill.
Build It!
With the thing planned and refined, it’s ready for work. At this point, a developer picks up the work and begins building it. During the building phase, developers will set up their environment for the work. They could be working on a local version, or they could be building it in production.
As code is being written, developers will work with other developers. Having other developers look at your code and review it helps this part of the process a lot. I’ll talk more about code reviews and the idea of Continuous Reviews in a future episode.
While the code is being written, the testers are writing test cases that will be used to test the thing. Developers test their own code to ensure it does what its supposed to do, but the real testing is done by testers in the next phase.
Testing
When the code is written for the thing, it typically moves into an environment for testing. This can be manually deployed, or it can be automatically built and deployed via a CI/CD process. I’ll have a future episode going over what these are.
Once the code is in place, a quality assurance person will start testing it. They will run through their test cases and they will try to break the thing if they can. If the tests pass, the thing is ready to move on to be released. If it is rejected, it goes back to the developer. Code can get stuck going to testing, being rejected and then sent back to the developer to fix. I call this the Churn. The Churn is not a good thing. A Churn is an indicator that better planning was needed or that the developer needs to spend more time testing before giving it to the tester. Another form of Churn is the business person not liking what was built. If this happens, it can go all the way back to planning, or even the birth phase.
I did want to note that there is a second tier that some companies use in testing called Regression Testing. This is the concept that the thing is deployed to a pre-production environment, along with other things that are ready to go to production. Regression is usually a suite of tests that are ran to ensure the software is still fully functional and that none of the new things have any side effects.
Release
Now that the thing is past testing, it’s ready to move into the real system, which we call production. To go in, it is best practice to have it approved. Once approved, it is scheduled to be deployed to production on an agreed upon date and time.
Once deployed, the thing could enter a beta phase where it is only rolled out to a subset of users, or it could just move into General Availability, or GA. When the thing is in the wild, problems can be found, these could be minor bugs or catastrophic failures. When this happens, a fix is made and tested and moved into production to fix the problem. These are called hotfixes.
After everything is finished and the new thing is doing what it should, the thing, from the perspective of the SDLC is at its end.
SDLC Management
Typically, a company will be building many things at any given time. Knowing the state of each thing and the details that describe it is key to success. Management can be done on paper, a whiteboard, a spreadsheet, etc. It can also be done using specialized software. Software such as Jira or VersionOne are used to track things as they move through the SDLC. In these systems, things can be called issues, tickets, stories. Stories are an agile term that is used to describe the thing from a specific perspective, such as a users perspective.
Things can really get crazy, or as I like to call it, awesome, when you start to synergize these systems with other systems. If a system like JIRA handles the state and the details of a thing, systems that manage the state of the code, or the code reviews, the building of the code, the deployment, the testing, etc., can be used either alongside or even as part of it. Atlassian, the maker of JIRA does this really well. I don’t want to play favorites here, but the Atlassian stack is just a great example of these different systems working in harmony. JIRA tracks the work, Bitbucket tracks the code, Crucible tracks the code reviews, Confluence tracks the documentation, Bamboo manages builds and deployments (I prefer Jenkins though).
Managing your SDLC is important and the tools you use to manage it is up to your company. I’ve used every form of SDLC management, but the day I started using a stack to manage everything, my entire existence as a developer changed.